Memories are an intricate part of most electronic systems, and are used to store data for a variety of applications. A random access memory (RAM) is commonly used in an integrated circuit or coupled to an integrated circuit on a printed circuit board. One common integrated circuit making use of a random access memory is a programmable logic device (PLD), such as a field programmable gate array (FPGA) or complex programmable logic device (CPLD). A dedicated random access memory block of a programmable logic device is commonly called a block RAM (or BRAM). When transferring data to or from any memory, it is necessary to ensure that a data transfer protocol is followed to guarantee that the correct data is properly written to or read from the memory. In some integrated circuits, a memory controller provides the function of ensuring that data is properly written to or read from a memory, whether the memory is internal or external to the integrated circuit.
An On-Chip Memory (OCM) controller, which is typically provided on an FPGA having a processor, serves as a dedicated interface between the BRAMs in the FPGA and signals available on an embedded processor. The signals are designed to provide quick access to a fixed amount of instruction and data memory space. The OCM controller, which typically comprises an instruction side on-chip memory (ISOCM) controller and a data side on-chip memory (DSOCM) controller, provides an interface to both an Instruction-Side Block RAM (ISBRAM) and a Data-Side Block RAM (DSBRAM). A designer of an FPGA can choose to implement any combination of ISBRAM and/or DSBRAM. A typical application for a DSOCM controller includes enabling a dual-port feature of BRAM to provide bi-directional data transfers between a processor and circuits of an FPGA.
It is also necessary to confirm that a circuit enabling data transfers is operating properly. A number of predefined data transfer functions (such as circuits implemented in configurable logic commonly called “cores” or intellectual properties (IP)) are often attached to a block under test. Conventional approaches for verifying the operation of a block under test interfacing with an IP is limited to verifying the internal operation of the IP itself, and not how the IP may be used. That is, it is difficult to determine whether the circuit coupled to an IP is properly implementing a data transfer protocol without knowing all of the signaling requirements of the IP. Additionally, it is difficult to provide all the combinations and permutations in which a signal, such as a signal in a variable latency data protocol, can arrive as an input from the IP. Consequently, a large number of test benches are required according to conventional methods to assert a signal in a particular sequence to verify that a circuit is implementing a particular data transfer protocol.
Further, there are also particular problems in transferring data between an IP and a DCOCM controller in a programmable logic device. For example, conventional DSOCM controllers have a fixed latency of operation. That is, data is read from or written to a memory of an FPGA in a fixed number of BRAM clock cycles. A fixed latency approach guarantees that the data load and data store operations are completed in a pre-determined, fixed number of BRAM clock cycles. This guarantees a deterministic performance between the DSOCM controller and on-chip BRAMs of an FPGA, for example. In addition to controlling a BRAM, the DSOCM controller may also interface with other peripheral devices, including for example hardware circuits of the FPGA or external RAM. Depending upon the circuits being controlled by the DSOCM controller, data may be sent to a circuit from the DSOCM controller or received by the DSOCM controller at different rates. However, because conventional DSOCM controllers only provide a fixed latency operation, these conventional DSOCM controllers will operate using conventional data transfer protocols based on a predetermined number of clock cycles.
Accordingly, there is a need for a method of and circuit for verifying a circuit implementing a variable latency data transfer protocol. There is a further need for a method of and circuit for verifying variable latency data transfers in electronic circuits, such as programmable logic devices, which allow different peripherals and on-chip memory to run at different speeds when they are attached to a DSOCM controller.